home *** CD-ROM | disk | FTP | other *** search
/ Workbench Design / WB Collection.iso / workbench werkzeuge / bootpicturetools / picboot / picboot.man < prev    next >
Text File  |  1996-04-07  |  28KB  |  739 lines

  1.  
  2.  
  3.    This file describes PicBoot, version 2.6, a program that shows an
  4. IFF ILBM or GIF picture during boot.
  5.  
  6. Introduction
  7. ************
  8.  
  9.    Have you removed all output in your 2.0+ startup, and only see a
  10. black screen during boot? Wouldn't it be nice to have a picture
  11. instead? A picture that disappeared when the Workbench screen opened?
  12.  
  13.    If so, PicBoot is certainly a program for you. What it will do is
  14. to read any IFF file containing an ILBM - or GIF - picture, and show
  15. it. As soon as the Workbench screen appears (or you press any
  16. mouse-button), the picture will go away.
  17.  
  18.    Features:
  19.  
  20.    *  Fast picture unpacking, using highly optimized assembler. The
  21.      entire picture is read into memory and then unpacked. This applies
  22.      both to the IFF and the GIF unpacker.
  23.  
  24.    *  Optional auto-detaching; the picture is loaded as fast as
  25.      possible, with minimal memory fragmentation.
  26.  
  27.    *  A picture can be shown a user-specified time after the
  28.      Workbench screen opens (see DELAY and PATCH).
  29.  
  30.    *  Extremely flexible argument parser.
  31.  
  32.    *  Random select among any number of pictures, in several different
  33.      ways.
  34.  
  35.    *  Force a certain display mode for a picture, even if saved with
  36.      another (can be selected on a picture by picture basis).
  37.  
  38.    *  The comment field of a file may be used to specify options.
  39.  
  40.    *  Optional screen centering (horisontally).
  41.  
  42.    *  Optional screen fading (in various forms). Uses the increased
  43.      palette range in AA (24 bits).
  44.  
  45.    *  Should work with most "Intuition emulators" for gfx-cards.
  46.  
  47. System requirements
  48. *******************
  49.  
  50.    Apart from OS 2.04+, PicBoot doesn't require any special
  51. libraries. The only non-ROM library required is iffparse.library
  52. (which normally resides in Libs:).
  53.  
  54.        PicBoot have full support for OS 3.0+ and AA graphics. It
  55. should even work with gfx-cards that have an "Intuition emulator".
  56.  
  57. Legal information
  58. *****************
  59.  
  60.    This program is freeware. You may copy and use this program freely,
  61. as long as the following conditions are met:
  62.  
  63.    *  All files are copied in an unmodified state. If additional
  64.      information is needed, place it in a separate file. Preferably
  65.      redistribute in the original archive form (*.Lha).
  66.  
  67.      Exception: So called BBS ads may not be added!
  68.  
  69.    *  The copying is done on a non-commercial and non-profit basis
  70.      only. A copy fee to cover media costs, postage etc. may be
  71.      charged. This fee may not exceed the fee to obtain an AmigaLibDisk
  72.      from Fred Fish.
  73.  
  74.    *  The copier/spreader is not claiming the Copyright © of this
  75.      program.
  76.  
  77.    Any exceptions from these restrictions requires written permission
  78. from the author, Magnus Holmgren (see Author contact).
  79.  
  80. Disclaimer
  81. ==========
  82.  
  83.    Magnus Holmgren neither assume nor accept any responsibility for the
  84. use or misuse of these programs. He also will not be held liable for
  85. damages or any compensation due to loss of profit or any other damages
  86. arising out of the use, or inability to use these programs.
  87.  
  88.    Magnus Holmgren will not be liable for any damage arising from the
  89. failure of these programs to perform as described, or any destruction
  90. of other programs or data residing on a system attempting to run the
  91. programs. While he know of no damaging errors, the user of these
  92. programs uses it at his or her own risk.
  93.  
  94. Usage
  95. *****
  96.  
  97.    To activate PicBoot, add a line to your S:Startup-Sequence,
  98. looking something like this:
  99.  
  100.      PicBoot Pics:Hi-res/Calvin01.Pic DETACH
  101.  
  102. Or, if you have a list of files in "Work:Text/PicList":
  103.  
  104.      PicBoot Work:Text/PicList LIST DETACH
  105.  
  106.    Or, if your drawer Pics:BootPics contains some pictures:
  107.  
  108.      PicBoot Pics:BootPics/#?.(Pic|Gif) DETACH
  109.  
  110.    This line should be located near the beginning in the
  111. S:Startup-Sequence (no point in placing it near the LoadWB
  112. command, is it? :), but keep it after SetPatchPicBoot will only
  113. output any text if it fails, so don't re-direct its output. Note however
  114. that if you place PicBoot before any additional monitors are
  115. installed, you'll be stuck with the default.monitor for showing your
  116. picture. The DEFAULT switch may be of help here.
  117.  
  118.    Make sure no program makes any output in the CLI window, since then
  119. the Workbench screen will open with a boring CLI-window instead...
  120.  
  121.    Options:
  122.  
  123. FILES
  124. =====
  125.  
  126.    This is the only required argument. Here you specify the name of the
  127. picture you want to view. You may enter several files here, in which
  128. case PicBoot will select one of them randomly, and show that one.
  129.  
  130.    The name(s) can also be the name of an ASCII file containing a
  131. filename list if you specified the LIST option.
  132.  
  133.    The name(s) can also be the name of a drawer, in which case
  134. PicBoot will randomly select one of the files in this drawer. To
  135. use a pattern during this scanning, simply enter the pattern like it
  136. had been the name of a file in the drawer. Example:
  137.  
  138.      Work:Pics/#?.gif
  139.  
  140. which would make PicBoot select a file ending in .gif in the drawer
  141. Work:Pics
  142.  
  143.    If the comment field of the selected listfile or picture starts with
  144. "*PicBoot*: " (case sensitive), then the rest of the comment is taken
  145. to be arguments, like those in a LIST file.
  146.  
  147.    You may freely mix picture and drawer names. Listfiles can only be
  148. mixed with the other two ones if the comment contains the LIST switch.
  149. In that case, the LIST argument should not be used on the command line
  150. (or in a list file). Ofcourse you can random select among list files
  151. with the "drawer scanner" if you like.. :)
  152.  
  153. MODEID
  154. ======
  155.  
  156.    Short form: M
  157.  
  158.    NOTE: This argument is mainly for the more "advanced" user.
  159.  
  160.    This argument should be a decimal number specifying which screen
  161. mode to use.  It basically replaces the so called CAMG hunk in an ILBM
  162. file (since it contains which screen mode to use). Thus, you must
  163. select mode with care, or else the picture will look like trash
  164. (nothing more serious can happen. I hope! :). When showing GIF files,
  165. it will override the internal "best mode" routines (which aren't good
  166. at all. But I haven't bothered to add code to make them better.. :).
  167.  
  168.    To make it easier for you to find out which display mode id to use,
  169. there is a small program called GetModeID included, which uses the
  170. ReqTools or Asl screenmode requester. Simply select the display
  171. mode you want, and it will print out the number you should use here.
  172. See GetModeID.
  173.  
  174.    The mode id will be passed through the same validity checking as a
  175. normal so called CAMG chunk, so PicBoot should handle bad values
  176. properly (although I haven't tested this much.. :).
  177.  
  178. LIST
  179. ====
  180.  
  181.    Short form: L
  182.  
  183.    If this switch is specified, PicBoot will interpret the files in
  184. the FILES argument as names of files containing a list of pictures (or
  185. rather, argument lines). PicBoot will then randomly select one of the
  186. lines in the selected file, and process it almost like a normal argument
  187. line. The only difference is that you can't use the DETACH, DELAY,
  188. PATCH or ACTIVATEWB arguments. These arguments may not be specified in
  189. a listfile (no point in doing it anyway).
  190.  
  191.    The listfile is an ASCII (text) file with a simple layout. On the
  192. first line you specify the number of argument lines in the file. This is
  193. usually <number of lines in file>-2 (one line is occupied by the count,
  194. and the other is the last linefeed). If this value is zero, then
  195. PicBoot will exit silently. The rest of the file is simply the
  196. argument lines to choose from. An example:
  197.  
  198.      4
  199.      Work:Pics/Comics/Calvin02.Pic MODEID 137220
  200.      Work:Pics/Comics/Calvin03.Gif
  201.      Work:Text/MoreCalvins.txt LIST CENTER ON
  202.      Work:Pics/Misc/#?.Gif
  203.  
  204.    Note that any arguments specified from the CLI, or in any previous
  205. listfile, will be taken as the new default value. In the listfile you
  206. may alter this default. This does not include the LIST argument
  207. (ofcourse). It is always turned off before parsing a line.
  208.  
  209.        Warning: Since you may enter a new listfile within a listfile,
  210. you can be caught in an endless loop, constantly changing (maybe to the
  211. same) listfile. No checking for this is done. Also, since there is no
  212. CLI-window around, you have no chance to send PicBoot any CTRL-C, if
  213. PicBoot should happen to listen to this. You have been warned! :)
  214.  
  215.        Note: A line in a listfile may not be more than 512 chars, or
  216. it will be truncated when read. This shouldn't cause any problems I
  217. think..
  218.  
  219. CENTER
  220. ======
  221.  
  222.    Short form: C
  223.  
  224.    Possible arguments: YES, ON, NO, OFF. Default is NO.
  225.  
  226.    If this switch is on (argument is YES or ON), PicBoot will center
  227. the picture. This centering should work fine for most screen modes, but
  228. one can never know.. :) If a screen promotor is active, then
  229. PicBoot can get it wrong (if the screen is opened in another mode
  230. than PicBoot had asked for).
  231.  
  232. DEFAULT
  233. =======
  234.  
  235.    Short form: DEF
  236.  
  237.    Possible arguments: YES, ON, NO, OFF. Default is NO.
  238.  
  239.    If this switch is on (argument is YES or ON), PicBoot will force
  240. the picture to use the default.monitor, regardless of what was actually
  241. stored in the picture (in the CAMG chunk). This is needed since very
  242. early in the startup, default.monitor is the only monitor available
  243. (e.g.  multiscan.monitor is normally not available). In the future, I
  244. might add more types of "forcing" (e.g. force a picture to PAL, NTSC or
  245. whatever that might be useful).
  246.  
  247.    This switch also acts on the MODEID parameter, if specified.
  248.  
  249. AUTOSCROLL
  250. ==========
  251.  
  252.    Short form: AS
  253.  
  254.    Possible arguments: YES, ON, NO, OFF. Default is NO.
  255.  
  256.    If this switch is on (argument is YES or ON), the OS 2.0+
  257. autoscrolling of screens will be enabled.
  258.  
  259.        Note: During boot, this switch may make the actual display a
  260. bit smaller than normally possible. There is nothing I can do about
  261. that... :) You can, however, by ensuring that ENV:/IPREFS is properly
  262. set up before PicBoot is started. Or you could try the VIDEOOVERSCAN
  263. switch.
  264.  
  265. VIDEOOVERSCAN
  266. =============
  267.  
  268.    Short form: VO
  269.  
  270.    Possible arguments: YES, ON, NO, OFF. Default is NO.
  271.  
  272.    If this switch is on (argument is YES or ON), the visible size of the
  273. opened screen will be as large as the system can handle (assuming the
  274. picture is large enough). Forces AUTOSCROLL to YES.
  275.  
  276. RTG
  277. ===
  278.  
  279.    Possible arguments: YES, ON, NO, OFF. Default is NO.
  280.  
  281.    If this switch is on (argument in YES or ON), then PicBoot will do
  282. things a little differently, in an attempt to make it work with
  283. gfx-cards (it have been tested with Picasso II). The main difference
  284. is that the screen is opened first, and the picture is decoded into
  285. this screen (usually the picture is decoded first, and then the screen
  286. is opened).  Thus, you should only use this switch if the picture
  287. should be shown with the gfx-card rather than the native Amiga
  288. graphics. If the gfx-card isn't used, the picture decoding may be a
  289. little slower.
  290.  
  291.    Oh, btw, RTG stands for ReTargetable Graphics.
  292.  
  293.        Note: This feature requires OS 3.0 to work. If you don't have
  294. OS 3.0, then this argument is ignored.
  295.  
  296.        Note: You might need to specify a new MODEID in order for
  297. PicBoot to use gfx-card screen.
  298.  
  299. WRITEPIXELLINE
  300. ==============
  301.  
  302.    Short form: WPL
  303.  
  304.    Possible arguments: YES, ON, NO, OFF. Default is NO.
  305.  
  306.    If this switch is on (argument is YES or ON), then PicBoot will use
  307. a ROM function to convert/write the pixel data of a GIF picture.
  308. Please note that this only have any effect if RTG have been used, and
  309. the opened screen isn't a native Amiga screen.
  310.  
  311.    In some cases, this can make PicBoot faster, but in others, it can
  312. make PicBoot slower. There is an explanation for this, but it is a
  313. bit technical. If you don't understand it (or you don't know enough
  314. about your gfx-card), then I suggest you test it a little, finding out
  315. which is fastest for different pictures.
  316.  
  317.    Most gfx-cards have a "chunky" screen. That is, each pixel is stored
  318. in one byte, which specifies which color (in a palette) that the pixel
  319. have. This is different from the native Amiga screen that have
  320. bitplanes (where the color number is spread over several bytes). Since
  321. a GIF picture stores the data in a chunky format, it would be a waste
  322. of time to first convert the chunky data to bitplane form, and then
  323. back again, if it should be displayed in a chunky screen.
  324.  
  325.    In that case (a chunky screen), this switch can improve the speed
  326. quite a lot, if a certain ROM function is patched by the Intuition
  327. emulator.  This patch should simply write the chunky data directly to
  328. the right area of the screen.
  329.  
  330.    However, not all gfx-card screens are chunky (at least the Picasso
  331. II stores 2-16 color screens as bitplanes), and perhaps the "Intuition
  332. emulator" haven't patched the above mentioned function. In those cases,
  333. then this switch will make things slower (since the original function
  334. (which converts the chunky data to bitplane form) is quite a bit slower
  335. than the routines in PicBoot).
  336.  
  337.    To test which is fastest, use something similar to the following
  338. commads:
  339.  
  340.      PicBoot Pics:Gifs/Island.gif RTG ON DETACH
  341.      PicBoot Pics:Gifs/Island.gif RTG ON DETACH WPL
  342.  
  343. and measure how long time both commands took to run (note that
  344. PicBoot detaches after the picture have been completely decoded),
  345. and only use the WPL switch if it made PicBoot faster.
  346.  
  347. FADEIN
  348. ======
  349.  
  350.    Short form: FI
  351.  
  352.    Argument range: 1 to 4. Default is no value.
  353.  
  354.    This value specifies the speed with which the picture should fade in
  355. when the screen is opened. HAM pictures can't be faded.
  356.  
  357. FADEOUT
  358. =======
  359.  
  360.    Short form: FO
  361.  
  362.    Argument range: 1 to 4. Default is no value.
  363.  
  364.    This value specifies the speed with which the picture should fade
  365. out when the screen is closed. HAM pictures can't be faded. Only useful
  366. in combination with DELAY (otherwise the picture will be in the back,
  367. were the fade isn't visible! :).
  368.  
  369. FADEWB
  370. ======
  371.  
  372.    Short form: FWB
  373.  
  374.    Argument range: 1 to 4. Default is no value.
  375.  
  376.    This value specifies the speed with which the Workbench screen
  377. should fade in when the picture screen have been closed. Intended to be
  378. used in combination with the FADEOUT (and DELAY) argument(s).
  379.  
  380. DELAY
  381. =====
  382.  
  383.    Short form: DL
  384.  
  385.    A "problem" with PicBoot is that the Workbench screen first
  386. opens, and then processes the Sys:WBStartup drawer, which takes a
  387. little time. This means that the picture PicBoot shows disappear
  388. before the boot is complete. To avoid this problem, the DELAY switch
  389. can be use to specify the number of ticks (there are 50 ticks each
  390. second) PicBoot will wait after the Workbench screen have opened.
  391.  
  392.    However, this isn't perfect. When the Workbench screen opens, the
  393. PicBoot screen must be brought back to the front again. This causes a
  394. little "flicker". To avoid this, use the PATCH parameter as well (this
  395. feature requires OS 3.0+ to work).
  396.  
  397.    There is a special delay value, 0, which causes PicBoot to wait
  398. until you either press any mouse button, or another program sends
  399. PicBoot a break signal (CTRL-C). The program StopPicBoot was
  400. written to do this.
  401.  
  402. PATCH
  403. =====
  404.  
  405.    Short form: P
  406.  
  407.    If this switch is specified, PicBoot will install a patch in
  408. Intuition, so that the Workbench screen (or rather, any screen
  409. opened, that explicitly doesn't say that the screen shouldn't open
  410. behind the others) doesn't open in front of the PicBoot screen. This
  411. removes the "flicker" that normally occurs when using the DELAY option.
  412. For this option to be useful, the DELAY parameter must be used as well.
  413.  
  414.        Note 1: This option only works on OS 3.0 or higher. This is
  415. due to the OS (as far as I know), and there is nothing I can do about
  416. it (tech note: Workbench in OS 2.0x doesn't seem to call the open
  417. screen function via the external library vector).
  418.  
  419.        Note 2: This kind of patching is not a recommended thing to
  420. do. Programs should not do temporary patches like this. However, to
  421. avoid the flickering, there is no alternative.. :)
  422.  
  423.        Note 3: In case some other program patches the same function
  424. after PicBoot have installed its patch - and you don't have a program
  425. like e.g. SetMan installed - then PicBoot will leave a small memory
  426. allocation behind (6 bytes), to avoid any problems.
  427.  
  428. DETACH
  429. ======
  430.  
  431.    Short form: D
  432.  
  433.    If this switch is specified, PicBoot will detach from its calling
  434. CLI when the picture is fully loaded and displayed. If you specify this
  435. option, you shouldn't "Run" PicBoot. This option will reduce memory
  436. fragmentation, and will ensure that the picture gets loaded quickly. I
  437. don't think this feature will cause any problems, but I added the
  438. switch just in case.
  439.  
  440. ACTIVATEWB
  441. ==========
  442.  
  443.    Short form: AWB
  444.  
  445.    If this argument is specified, then PicBoot will try to activate a
  446. Workbench window after closing the picture. This might be useful if
  447. you are using the DELAY argument.
  448.  
  449. Known problems
  450. **************
  451.  
  452.    I do not know of any real bugs in PicBoot. However, certain parts
  453. of the program may still contain bugs. E.g.,  pictures that have a mask
  454. bitplane (mskHasMask) are supported, but since I only have one
  455. (compressed) picture that have a mask, there might be a bug in that
  456. code (can't test it properly).  Please report any problems!
  457.  
  458.    Currently there is no support for SHAM, PCHG and similar pictures.
  459. I'm not sure if this could be implemented in a "clean" way (that would
  460. work on future systems etc). These pictures aren't that common, and I
  461. have an Amiga with AA-graphics, so... :) Color cycling is currently
  462. ignored (I have no need for it).
  463.  
  464.    Interlaced GIF pictures aren't supported, since I don't have any such
  465. picture (well, actually I have ONE :). Besides, the decompression of
  466. such pictures would be slower anyway.
  467.  
  468.        PicBoot doesn't remap GIF files in any way. Even if you have
  469. ECS, GIF files can still be useful. This is because a GIF file can have
  470. from 2 to 256 colors (inclusive). Thus, if you have a program that can
  471. save a 16-color picture as a 16-color GIF file, there will be no
  472. problem to view it with PicBoot.
  473.  
  474.        PicBoot doesn't make use of any "chunky to planar" hardware,
  475. if it should happen to be installed (e.g. Aikiko). Anyone who have it,
  476. so I can test it if I should decide implement it? :) It would be fairly
  477. simple to do, since my own (rather fast, I might add :) chunky to
  478. planar routines have very similar restrictions.
  479.  
  480.    The "best mode" routine used in the GIF reader isn't good at all
  481. (this includes the ROM function in OS 3.0+! :). I suggest you use the
  482. MODEID parameter instead (Correction: The ROM function isn't good when
  483. there are several different monitors to choose from. If only one or two
  484. (similar) monitors are available, then the result is usually rather
  485. good).
  486.  
  487.    Pictures with more than 8 bitplanes are currently not supported by
  488. PicBoot.
  489.  
  490.    The centering for (some?) Super72 screens doesn't work. I suspect
  491. this is an OS-"bug" (I know that PicBoot calculates a reasonable
  492. offset, which Intuition seems to ignore).
  493.  
  494. StopPicBoot
  495. ***********
  496.  
  497.        StopPicBoot is a small program that simply tells PicBoot to
  498. quit, if it should happen to be in memory. This is useful in
  499. combination with the DELAY option. If this is set to 0, PicBoot
  500. expects someone to tell it when it is time to exit, and this is what
  501. StopPicBoot does.
  502.  
  503.    By having StopPicBoot in Sys:WBStartup, then PicBoot will
  504. close its screen when the boot process almost complete (the tooltype
  505. STARTPRI should be very low (-120 or so), so that StopPicBoot is
  506. started as the last program)
  507.  
  508. GetModeID
  509. *********
  510.  
  511.        GetModeID is a simle program that shows a Asl or
  512. ReqTools screenmode requester, whichever is available. The program
  513. will then print out the decimal identifier for the selected screenmode,
  514. suitable for use together with the MODEID parameter. This program can
  515. only be used from a Shell. Example usage:
  516.  
  517.        PicBoot Island.Gif MODEID `GetModeID`
  518.  
  519.    This will first show a screenmode requester (if you have one, that
  520. is), and then show the GIF-picture in the selected screenmode.
  521.  
  522. UnpackILBM
  523. **********
  524.  
  525.        UnpackILBM is another simple program (at least in theory...
  526. :). It will take any IFF ILBM picture and unpack the so called BODY
  527. chunk in it (this is the actual image data). This means that e.g.
  528. PicBoot will be able to display that image a little faster, at
  529. least if loading it from some fast media. Or, if you use
  530. PPShow/ShowIFF, you could repack the picture with
  531. PowerPacker/Xpk, to maximize the compression (as the
  532. compression used in IFF ILBM isn't a very efficient one. But on the
  533. other hand, it is rather fast and simple). But then PicBoot won't be
  534. able to load them.. :) Example usage:
  535.  
  536.        UnpackILBM Island.Pic Island.Pic.NoComp
  537.        UnpackILBM Island.Pic
  538.  
  539.    The first example till unpack the picture to a new one, while the
  540. other will - via a temprary file - overwrite the original picture with
  541. the uncompressed version.
  542.  
  543.        Note: I haven't tested this program that much. I've converted
  544. a few pictures, so it seems to work fine (at least when there aren't any
  545. errors), but one can never now.. Please report any problems!
  546.  
  547.        Note: This program doesn't strip any information. All chunks
  548. will remain. The picture data is only decompressed.
  549.  
  550. Author contact
  551. **************
  552.  
  553.        PicBoot was written by Magnus Holmgren. If you have any
  554. comments etc, feel free to send me a note. You can reach me via
  555. internet on this address:
  556.  
  557.      cmh@augs.se
  558.  
  559.    Fido-net messages should go to "Magnus Holmgren",
  560. 2:204/404.6@fidonet.org.  Snail mail should reach me if you write the
  561. following address on the envelope:
  562.  
  563.      Magnus Holmgren
  564.      Kvarnbergsvägen 4
  565.      S-444 47  Stenungsund
  566.      SWEDEN
  567.  
  568. Version history
  569. ***************
  570.  
  571. Version 1.00-1.03
  572. =================
  573.  
  574.    Ancient versions.
  575.  
  576. Version 2.0
  577. ===========
  578.  
  579.    Release date: 29 Mar 94
  580.  
  581.    *  BLACK argument removed. Not needed any more, since PicBoot now
  582.      will first allocate the needed memory, decode the picture into
  583.      this memory, and then open the screen. This makes the screen
  584.      opening/closing a little faster too (practically instaneous on my
  585.      A4000/040).
  586.  
  587.    *  Pictures (or rather, brushes) that were less than 16 pixels wide
  588.      wouldn't decompress properly... :)
  589.  
  590.    *  Added support for the CMAPOK flag in the BitMapHeader.bmh_Flags
  591.      (previously called bmh_Pad) field (if this flag is set it
  592.      indicates that the color map contains 8 bits/color rather than 4
  593.      bits/color).
  594.  
  595.    *  Major code cleanup. Made the program somewhat larger, but... :)
  596.  
  597.    *  GIF support added. Should be a little faster than PPShow.. :)
  598.  
  599.    *  The MODEID argument wasn't properly "passed on" to any following
  600.      listfile(s).
  601.  
  602.    *  Rewrote rtGetModeID into GetModeID, that first checks for
  603.      Asl, and then tries with ReqTools before giving up. This new
  604.      version is in C, compiled with DICE, without any startup code, and
  605.      is fully residentable. :) See GetModeID.
  606.  
  607.    *  Included UnpackILBM, that takes any IFF ILBM file (with a BODY
  608.      chunk, i.e. a normal picture) and writes it with an uncompressed
  609.      BODY instead. Written upon user request. See UnpackILBM.
  610.  
  611. Version 2.1
  612. ===========
  613.  
  614.    Release date: 14 May 94
  615.  
  616.    *  The DEFAULT parameter didn't do anything. Fixed
  617.  
  618.    *  UpackILBM and GetModeID updated a little. Version string
  619.      added, recompiled with DICE 3.0 and some other minor changes.
  620.  
  621. Version 2.2
  622. ===========
  623.  
  624.    Release date: 12 Jul 94
  625.  
  626.    *  If the listfile was too short (i.e. not enough number of lines in
  627.      it), PicBoot would crash.
  628.  
  629.    *  Made the detaching code more system friendly. I hope this will
  630.      fix the problems a few users have had.
  631.  
  632.    *  A few minor bugs fixed + some minor optimizations...
  633.  
  634.    *  If the number on the first line in the listfile is 0, then
  635.      PicBoot will exit silently. Now why did I add this... >;)
  636.  
  637.    *  Improved the random number algorithm.
  638.  
  639.    *  Added the DELAY parameter.
  640.  
  641.    *  Added the PATCH parameter.
  642.  
  643.    *  Tweeked the GIF-unpacker a little. Found yet another Macro68
  644.      (V3.170) bug while doing that.. :/ (Watch out for bra.l to other
  645.      sections/modules when generating code for the 68020+. The branch
  646.      target is not correct. :)
  647.  
  648. Version 2.3
  649. ===========
  650.  
  651.    Release date: 30 Aug 94
  652.  
  653.    *  Rewrote startup code and argument parser in C, for easier
  654.      maintainance (and to simplify the implementation of some of the
  655.      features below).
  656.  
  657.    *  You can now also specify a directory (with optional pattern
  658.      matching), and PicBoot will randomly select among the files
  659.      found. As usual, you can use this feature whereever PicBoot used
  660.      to expect a file name.
  661.  
  662.    *  If the comment field of a file that PicBoot will read (i.e. a
  663.      list file or a picture) starts with the string "*PicBoot*: " (case
  664.      sensitive), then the rest of the comment is assumed to be
  665.      arguments, to be parsed like they had been found in a list file.
  666.  
  667.    *  UnpackILBM will not delete the temp file if it couldn't be
  668.      renamed to the original.
  669.  
  670.    *  Removed a piece of debug code in the OpenScreen() patch (it
  671.      flashed the screen). Harmless, but annoying.. :)
  672.  
  673. Version 2.4
  674. ===========
  675.  
  676.    Release date: 11 Oct 94
  677.  
  678.    *  Added the arguments FADEIN, FADEOUT and FADEWB, to make various
  679.      color fades when the screen is opened/closed.
  680.  
  681.    *  Modified the random routines again (changed the seed source). I
  682.      hope it works better now.. :)
  683.  
  684.    *  If DETACH was used and a relative filename was used, then the file
  685.      wasn't found (except in some cases).
  686.  
  687.    *  Using PATCH in combination with DELAY on pre-OS 3.0 systems
  688.      caused a "Not enough memory" message to be printed, and the picture
  689.      wasn't showed (the argument should silently be ignored).
  690.  
  691.    *  Some error messages lacked a final linefeed char (an autodoc was
  692.      a bit misleading.. :).
  693.  
  694.    *  The DELAY was incorrectly interpreted as seconds, and not as
  695.      ticks.
  696.  
  697.    *  Closing the picture before a DELAY timeout had expired caused a
  698.      crash.
  699.  
  700. Version 2.5
  701. ===========
  702.  
  703.    Release date: 13 Oct 94
  704.  
  705.      The Workbench screen wasn't "unlocked" in some cases (when either
  706.      FADEWB or ACTIVATEWB had been used).
  707.  
  708. Version 2.6
  709. ===========
  710.  
  711.    Release date: 30 Nov 94
  712.  
  713.    *  Added RTG switch, which will make PicBoot attempt to be more
  714.      compatible with various "Intuition emulators" for gfx-cards. Don't
  715.      use this switch if you don't need to; it will cause the screen to
  716.      be opened before the rendering (possibly making it slower).
  717.  
  718.      Also added WRITEPIXELLINE, which may improve the speed of the GIF
  719.      reader sometimes, when using the RTG-mode.
  720.  
  721.      Thanks go to Roger Westerlund, who made me actually try to make
  722.      PicBoot RTG friendly, and also did all the needed testing (I
  723.      don't have any gfx-card :/).
  724.  
  725.    *  Changed the screenmode id "validator". Needed for better RTG
  726.      compatibility.
  727.  
  728.    *  Some fade related code was a bit broken, causing problems with
  729.      e.g.  HAM-pictures.
  730.  
  731.    *  UnpackILBM is now able to decompress via a temporary file if the
  732.      file and the current directory are on different volumes. Also
  733.      improved some error reporting.
  734.  
  735.    *  GetModeID now filters out some useless modes (the dual payfield
  736.      (DPF) ones). Also, the ReqTools screen mode requester didn't
  737.      show "non standard" modes (such as HAM and EHB).
  738.  
  739.